home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / std / c++ / 1158 < prev    next >
Encoding:
Internet Message Format  |  1996-08-06  |  3.1 KB
  1. Path: engnews1.Eng.Sun.COM!taumet!clamage
  2. From: Rob Stewart <stew@datalytics.com>
  3. Newsgroups: comp.std.c++
  4. Subject: Re: Better template syntax?
  5. Date: 18 Apr 1996 16:54:19 GMT
  6. Organization: Datalytics, Inc
  7. Approved: clamage@eng.sun.com (comp.std.c++)
  8. Message-ID: <317673A9.2EBB@datalytics.com>
  9. References: <31741E6C.53CA@cs.tu-berlin.de>
  10. NNTP-Posting-Host: taumet.eng.sun.com
  11. Mime-Version: 1.0
  12. Content-Type: text/plain; charset="us-ascii"
  13. Content-Transfer-Encoding: 7bit
  14. X-Nntp-Posting-Host: 204.62.224.71
  15. X-Mailer: Mozilla 2.0 (WinNT; I)
  16. X-Lines: 51
  17. Content-Length: 2155
  18. Originator: clamage@taumet
  19.  
  20. Roman Lechtchinsky wrote:
  21. > 
  22. > Hi,
  23. > 
  24. > sorry for being curious but I'm only human... My question is: when declaring
  25. > templates, why isn't it required to declare what one expects of the
  26. > template's parameters? Let's create a template function:
  27. > 
  28. > template<class T> bool equal( const T& t1, const T& t2 )
  29. > {
  30. >   return t1==t2;
  31. > }
  32. > 
  33. > Now, personally I would prefer to write something like:
  34. > 
  35. > template<class T { bool operator==( const T& t ) const; }> ...
  36. > 
  37. > This would make both the development and the use of templates much easier (
  38. > to me, at least ). No need for writing lots of comments explaining what
  39. > interface T should provide; no need for reading the source code of "equal" if
  40. > it is part of a third-party library with poor interface documentation; no
  41. > need to worry about implicit conversions - sounds like a lot of advantages.
  42. > Then again, I imagine that this approach would make templates more efficient
  43. > and easier to implement.
  44. > Now, what I'd like to know is if something like this has been considered and
  45. > rejected ( and why ) and what other people think about it ( would this be
  46. > really easier to use in practice; do you consider it more elegant than the
  47. > current approach ). Thanks in advance.
  48. > 
  49.  
  50. I can't answer whether this has been considered (or rejected), 
  51. but I can see a problem with your proposal.  What if a template 
  52. required ten, fifteen, twenty mfs in its parameterizing type?  
  53. What if those mfs have many parameters?  The resulting list of 
  54. mfs and parameters would become quite ungainly.
  55.  
  56. Perhaps you could declare a class with the exact interface you 
  57. expect and provide that as a model for the parameterizing type?  
  58. This still leaves issues like equivalence.  Are implicit 
  59. conversion allowed in mfs of a parameterizing type in order to 
  60. match the model?  At what point do you decide there is no match?
  61.  
  62. What about the template code?  What if it you misuse the 
  63. parameterizing type relative to your model?  Is the model wrong 
  64. or is your code wrong?
  65.  
  66. There's probably a lot more I haven't thought of yet.
  67.  
  68. -- 
  69. Robert Stewart        | My opinions are usually my own.
  70. Datalytics, Inc.    | stew@datalytics.com
  71.  
  72.  
  73. [ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
  74. [ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
  75. [ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
  76. [ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
  77. [ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]
  78.